Language/OS - Multiplatform Resource Library/LANGUAGE OS.iso/dsp/dspgroup/cis_dsp.arc/CIS_DSP3.TXT

Text File | 1988-04-07 | 94.7 KB | 2,220 lines

#: 72543 S17/TAPR NNC/DSP
    23-Mar-88  09:41:59
Sb: #72508-Access Request
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob McGwier N4HY 74615,1366

OK. I hope the 256k x 1 chips come out though so you can have 256k and less
board space!

Lyle

*** More ***

#: 72544 S17/TAPR NNC/DSP
    23-Mar-88  09:43:43
Sb: #72540-#DSP SW
Fm: Lyle Johnson, WA7GXD 76246,565
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry,

The main problem with having lots of options (or even one major one) is that,
once you have the better A/D and D?A, the code that will get written will
assume their presence.  This makes folks who buy the system in a normal
configuration feeling like they are a target of the old bait-and-switch game.
One advantage of the D-S Model 10 that you all are using is that they are all
the same.  If each of you had a different analog front end, testing code and
exchanging programs would be a lot more difficult.

On balance, the next generation DSP card will probably have a place for a
daughterboard and the daughterboard will be the analog subsystem.  Hopefully,
we can select a reasonably high-performance "normal" analog front end that will
keep most folks happy.  But those who want to go for gusto will have a simple
means of doing so.

The 32041 analog front end takes another 3 TTL chips to glue to the 3201x as
well as extra clock dividers.  Motorola has announced a new linear codec with
13 bits range and 9 bits resolution.  It is cheaper than the TI part -- but
only the data shet exists at this time.  Such parts attach directly tothe 3202x
and 5600x parts, however.  These parts are limited to a 16-20 kHz sample rate.

The only 12-bit system that I can find that is affordable adds about $22 to $25
to the cost of the 3201x board, and is limited to about 32 kHz on the A/D side.
Apart from hitting the wall on the cost issue, I suspect the 8-bit fast A/D and
D/A subsystem is the best overall choice, but I have been wrong before!  I'll
add you to the destination of the preliminary schematics and you can take a
look.

Lyle



*** There is a reply:   72586

*** More ***

#: 72586 S17/TAPR NNC/DSP
    24-Mar-88  05:02:52
Sb: #72544-DSP SW
Fm: Phil Karn, KA9Q 73210,1526
To: Lyle Johnson, WA7GXD 76246,565 (X)

Lyle,

I think it should be possible to design the board so you can plug in
your choice of A/D converter.  If you're willing to pay, you get the
high resolution unit, otherwise you get the cheapie 8-bit A/D.  As long
as the software sees the high order bit in the same place, it doesn't
really care that you're padding the low order bits with zeros.
Performance will suffer, but that's what you sacrifice for the lower
price.

Phil

#: 72577 S17/TAPR NNC/DSP
    23-Mar-88  23:09:34
Sb: skiz enroute tomorrow
Fm: Lyle Johnson, WA7GXD 76246,565
To: dspers

DSPers,

I got the TMS3201x board shcematic about 98% complete, plotted and going out to
you all tomorrow, along with a couple pages of notes and questions and a copy
of the pertinent portions (perhaps all?) of the AD7569 8 bit analog port data
sheet.  I assume you have the rest of the data sheets you might need.

I will be working on the V40 part, and the power supply, over the next few days
while I await feedback.

For a cabinet I am thinking in terms of a TNC 1 size rather than a TNC 2 size,
since this box will evenutaly be holding a V40, the 3201x and maybe a 5600x.
So, start pushing your other junque aside and get some space on your operating
desk!

IC count is 28, I haven't done a PC size estimate yet. We have a 40-pin chip, 5
24-pin skiny DIPs, 18 20-pin DIPs, 2 16-pin DIPs, 1 14-pin DIP and an 8-pin
DIP.  There is a single analog output, a single analog input, a user 16-bit
digital output and a 16-bit input.  Then there is an 8-bit input and 8-bit
output port to the V40, along with an 8-bit input and 8-bit output for serial
I/O tothe 8530 and miscellaneous other stuff.  It look slike only 4 chips and
the op amp aren't CMOS.  I have to check on price and availability to see if we
can get CMOS FACT in the functions we need.  If so, the whole shebang will be
CMOS (including the PAL)!  Oh yes, the TBLW address space is 4k less the 8
lowest words for I/O. :-)

Lyle

#: 72589 S17/TAPR NNC/DSP
    24-Mar-88  09:52:55
Sb: #72502-RE: HF Modem DSP #2
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366

I admit deriving a good clock from random m-ary data is not a piece of cake.
One other possibility we might want to consider: acquiring clock only during a
bit sync preamble at the beginning of the transmission and then holding the
timing for the duration.  In this way we could make the clock recovery very
robust since we'd be using all the signal power and plenty of transitions
during the acquisition phase.  This should be more efficient than the other
schemes, since they would require a bit sync preamble in any case.  We would
just make it a little longer and more robust, and then pour all available
energy into getting the signal through once we've acquired bit timing.

Which model Nakamichi do you have?

#: 72617 S17/TAPR NNC/DSP
    24-Mar-88  16:46:11
Sb: #72544-DSP SW
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

Funny you should mention analog front ends on the D-S board all being the same.
In fact, I am in the process of piggybacking a new front end on the one I
have... just gotta have another analog input!  This is what happens when the
original design has severe built-in limitations.

Your point about the 'bait and switch' syndrome is well taken... however, I
think we are talking about at most two different analog front ends, not a whole
bunch of them.  Those of us writing code could certainly accommodate both
possibilities, and in many cases this might involve changing just one
instruction (which could be done automagically in the software by testing for a
jumper setting or some such).  No software changes at all would be needed if
the hardware arranged that the MSB always appeared in the same place.  The
motivation for upgrading would be to obtain higher performance, less finicky
adjustments, etc... not to avoid being left out in the cold because the
software won't run with 8b conversion.

It's too bad A/D converters don't have standard pinouts like EPROMs, so you
could just pull out the 8b and pop in a 12b unit!  I hadn't looked at the
problem of interfacing the 32041 to first-generation 320's... sounds like a
non-contender from your description.  Not cheap either.  How does the price of
a 12b converter look if we lowered our expectations for sample rate?  After
all, many applications, such as the HF stuff, only need a sample rate of 6-12
kHz or so.  What I'm thinking of is a board with two ports devoted to analog
input.  One would have the fast 8b A/D, which would be present on all boards.
The other would have a socket for the optional 12b converter, which could be
used for lower sample-rate, higher dynamic range applications.

I won't belabor the point further.  This will be a neat box of tricks no matter
what!

Barry

#: 72633 S17/TAPR NNC/DSP
    24-Mar-88  21:21:50
Sb: #72540-DSP SW
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Okay.  That is fine with me.  I wasn't thinking of putting this all together
before then anyway.  We have to get all the lists of folks to Cris at the
TAPR office and get the disks made up.  Tom will be out of town until this
weekend, I will be in DC next week and not long after that I will be in the
UK for two weeks.  Though I am as excited about this as everyone else, I do
work for a living (believe it or not!).
Bob



#: 72647 S17/TAPR NNC/DSP
    24-Mar-88  23:23:54
Sb: #72586-DSP SW
Fm: Lyle Johnson, WA7GXD 76246,565
To: Phil Karn, KA9Q 73210,1526 (X)

Phil,

Understood.  The problem comes in trying to decide which A/D and D/A will be
best for everyone.  If I pick a particular pinout, you're stuck.

Thus, what I am providing are "spare" latched/buffered 16-bit input and output
ports, along with decode strobes from the I/O area and clock signals.

This way, a person can add what they like.  It probably locks out the use of
some parts, but, oh well, this is the low end unit...  The high(er) end unit
will have piggyback boards for analog functions, as well as FIFOs on the A/D
and D/A so you can process in bursts while you sample smoothly.

I'll mail you the stuff I'm sending out today.

Lyle

*** More ***

#: 72648 S17/TAPR NNC/DSP
    24-Mar-88  23:26:21
Sb: #72617-DSP SW
Fm: Lyle Johnson, WA7GXD 76246,565
To: Barry McLarnon VE3JF 71470,3651 (X)

Barry,

The crystal semi range of a/ds have compatible pinouts from 12 to 14 to 16
bits. but the 12 bitter is about $40... sigh.

Lyle

*** More ***

#: 72634 S17/TAPR NNC/DSP
    24-Mar-88  21:21:58
Sb: #72543-Access Request
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Great.  I have just been calculating all that we wish to do that needs EDAC
and by golly 128K is going to be a squeeze so the 256K won't break my heart
at all.
Bob


*** More ***

#: 72636 S17/TAPR NNC/DSP
    24-Mar-88  21:22:28
Sb: #72589-#RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

That is a way, I am ever so afraid of open loop control systems however,
sure would like some ability of doing phase readjustment during the data
transfer.  If we do the coding by having a small number of bits choosing
between groups (and thus part of the data) and guarantee that at least one
was always on, we could use them to have a closed loop (PLL like) clock
recovery circuit.  Your method is indeed the simplest but we are not wasting
power with the technique I am proposing since the guaranteed on tones are
transmitting <at least> one bit of data and it could be more.
Bob


*** There is a reply:   72666

*** More ***

#: 72666 S17/TAPR NNC/DSP
    25-Mar-88  03:51:24
Sb: #72636-RE: HF Modem DSP #2
Fm: Phil Karn, KA9Q 73210,1526
To: Bob McGwier N4HY 74615,1366 (X)

Because the HF channel has random, time-varying propagation delay, it
will always take *some* fraction of the signal energy to convey symbol
timing.  How much depends on how fast the delay varies, plus other
requirements like packet lockup time.  Can anyone put numbers on these?

Actually, you have a fair bit of design latitude in how much bandwidth
you spend on the clock, especially with a M-ary system.  Consider having
two different signal sets that you alternate between on each symbol.  If
you have, say, 32 allowable symbols and you use only half of them on
each bit, you are spending 1/5 of your bandwidth on the clock.

Think of it as a generalization of Manchester, where the only choice you
get is to spend half your bandwith on the clock.

It might also be worth looking at the various papers that have been
written about channel encoding for the Compact Disk.  Their primary
concern was in shaping the spectrum of the signal fed to the laser; low
frequencies had to be eliminated to make the tracking servos work, and
high frequencies of course could not exceed the resolution of the laser
spot.  They ended up with something called Eight-to-Fourteen Modulation
(EFM).  A simple ROM table lookup translates 8 bits from the FEC coders
into 14 bits that are actually written on the disk.  The codewords were
chosen by computer search based on the given constraints.  While an HF
modem is quite different from the CD, the design techniques may still be
useful.

Phil



*** More ***

#: 72641 S17/TAPR NNC/DSP
    24-Mar-88  22:17:44
Sb: #72577-skiz enroute tomorrow
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Great.  I was looking forward to it.  Possibly I shouldn't open it up until
the current conflict of interest that Tom and I find ourselves in is worked
out.  I will return them unopened by registered mail.
I would like to point out to both Phil and Barry that we decided on
a target for this first board, the computer user end of Joe and Mary HT.  We
are also very much interested in building a second unit that you and I will
be able to pay $1000 for and get all the whiz bangs on it we want.  Remember
this a TMS320C10 not a Cray XMP.   The follow on, with a second generation
TI or high end Motorola or ?? will be 10 MIPS with sixteen bit A/D and
multiple ports, etc.  We also need $$$ to pay for the engineering of this
the ultimate communications tool.  Sorry folks, we just don't agree on this
one.  I just do NOT believe that we can sell something that costs
significantly more than the PK-232 because that is what we will be able to
deliver with several more modems than the 232.  All of the modems we wish to
do for this are a cinch with 8 bit.  If it doesn't drive the price up
significantly, I don't mind there being a A/D disconnect jack ;-)
Bob

#: 72825 S17/TAPR NNC/DSP
    28-Mar-88  00:28:35
Sb: #72476-RE: HF Modem DSP #2
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Re the clock recovery: I have the gut feeling that we have to
guaranteee a clock transition during each and every baud time.
Something like Manchester coding doesn't help on HF since the
signalling elements are only half as long (before you re-add the
two half-bits back together). Unless we do some sort of bit stuffing
(a la HDLC), I'm not certain we can guarantee a clean clock transition
in each signalling element. That was the rationalle behind my
suggesting one tone as an OOK (or FSK) clocker. But any other
more brilliant ideas are welcome!

#: 72838 S17/TAPR NNC/DSP
    28-Mar-88  09:15:43
Sb: EME DSP
Fm: Alberto E. Zagni I2KBD 71360,3467
To: Bob McGwier N4HY 74615,1366

Dear Bob, I spent this weekend working on EME DSP. Conditions were 120 W, 2 X
21 element Tonna and 0.5 dB GasFET on 432. With Doppler 800 Hz some marginal
echos were detected within +- 50 Hz. No outstanding peak out of the noise did
show up with SPECT1K and I plan to add it some stathistics to }ishow the number
of peaks detected out of 5 minutes, that fall within a given 100 Hz interval
(moon scatter). Have you done any further work on this software? Happy Easter
and all the best, Alberto I2KBD

#: 72867 S17/TAPR NNC/DSP
    28-Mar-88  16:43:15
Sb: #72724-dsp56001
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

I believe that we are in a big enough hurry that we don't change horses this
late.  You ought to have four floppies full of pkarc'd programs written in
TMS320C10 (and C15) assembler.  It will be a while until we come close to this
on the DSP56001.  I wondered why those SOB's were suddenly being so nice in
giving away all these expensive toys to us after a year of saying no.  I have
spent very little time writing code for the Motorola believing that we should
concentrate on getting the DSP-2001 ready.  It was only three weeks ago that I
became convinced that the Motorola chip was a better second generation product
than the TI chip. Bob




#: 72877 S17/TAPR NNC/DSP
    28-Mar-88  17:52:01
Sb: #72866-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

YES!  I like the Miller coding idea.  That is the way to do it.  It is
really just about time to get on with finishing this first FFT block I
began before the blasted AMSAT bored of directors meeting and try and take a
cut at some kinda host interface.
Bob



#: 72878 S17/TAPR NNC/DSP
    28-Mar-88  17:52:12
Sb: #72865-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

I have one of those at work which they allow me to bring home when I want
to.  It is nice to be able to save my money for Dayton and all the mode L
gear I want.
Oh BTW, let me throw a shocker at you.  Karl Meinzer has dropped a bloody
pile of pooh pooh on us.  We (of course) have been pushing Mode B in our
publicity for Oscar 13.  He says that after startup gonna switch to Mode J
and L (combined in one transponder) and that Mode B will remain VVEERRYYY
quiet.  Glad I tuned up for Oscar 12 and have been saving sheckles fer Mode
L anyway!
Bob


*** More ***

#: 72879 S17/TAPR NNC/DSP
    28-Mar-88  17:52:25
Sb: #72838-EME DSP
Fm: Bob McGwier N4HY 74615,1366
To: Alberto E. Zagni I2KBD 71360,3467 (X)

Marginal echoes is all there is at that level and a statiscal decision
algorithm is all that will work.  The distribution will most likely have to
be empirically derived and Tom came up with a candidate some time back that
I have yet to encode. That is the reason for the LLOONNGGG signalling
elements in our proposals.  Right +/- 50 is about right for the poorer days
as far as dispersion goes.  This is going to be a lot of work and we have
put all of that on the back burner to get some of the code needed for the
hardware that we have been discussing here ready.  Glad you are working on
it!
Bob

#: 72890 S17/TAPR NNC/DSP
    28-Mar-88  20:04:04
Sb: update
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Dan has offered some comments on the circuit diagram sent out last week.

1) There needs to be a way to have an in or an out initiate an A/D conversion.
This would allow a software loop to control everything without an external
timer.

2) The external timer (assumed controlled by the V40) should have a mechanism,
if practical, to allow direct control by the TMS3201x.

---

One of Dan's big concerns is the software for the V40 coprocessor.  If the V40
handles the timer, there may be an unknown latency factor which could confuse
the DSP chip.  The old question of *who* will program the V40 once again
arises.

---

Wednesday, Dan and I will meet in Eric's hospital room and discuss things
further.  I will report on Eric's coments and further developments in the
hardware design evolution afterwards.


#: 72898 S17/TAPR NNC/DSP
    28-Mar-88  20:49:13
Sb: #Names
Fm: Lyle Johnson, WA7GXD 76246,565
To: Board

I am happy with DSP 1.  Scott, what you print will be it.  Like Pete with the
color of the TNC 1 cabinet, I don't have strong feelings.

Lyle

*** There is a reply:   72909

*** More ***

#: 72909 S17/TAPR NNC/DSP
    28-Mar-88  21:30:38
Sb: #72898-Names
Fm: HamNet SysOp Scott W3VS 76703,407
To: Lyle Johnson, WA7GXD 76246,565 (X)

OK, since you and Bob seem to agree on DSP-1, I'll change it to that unless
anyone else votes strongly the other way.

Scott


#: 72899 S17/TAPR NNC/DSP
    28-Mar-88  20:50:08
Sb: 56001
Fm: Lyle Johnson, WA7GXD 76246,565
To: Bob

Bob,

No, I'm really sugesting we change.  Mot makes a translator program, but I was
just amazed atthe price change (still trying to verify it).

Onward with the 32015!

Lyle


#: 72901 S17/TAPR NNC/DSP
    28-Mar-88  20:50:49
Sb: Chuck's Comments
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSpers

I have uploaded Chuck's comments on the mailing as chuck1.dsp.

Lyle

#: 72972 S17/TAPR NNC/DSP
    30-Mar-88  00:17:19
Sb: #72825-#RE: HF Modem DSP #2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640

What's your rationale for wanting a clock transition every baud time?

*** There is a reply:   73031

*** More ***

#: 73031 S17/TAPR NNC/DSP
    31-Mar-88  09:29:50
Sb: #72972-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365

Don't need it every time and I don't think he wants it every time, just
easier to recover clock from a tone that is going on-off at the clock rate.
I am ftp'ing your stuff over from TOMCAT now.  Tom called me FIVE times last
night saying how wonderful it was, I can't wait to try it.  Maybe you will
let distribute it with the rest of the DSP stuff and also allow us to take
the FFT routine out of your code, replace it with a poll to DSP board to see
if done and use the rest of your code to the the grunt work that we have
been very bad about getting around to doing.  There are in fact starting to
be some surplus A/D boards and don't see why we couldn't make a `cheappy'
A/D board for those who wanted to do DSP on the PC itself.  Of course, with
the drive to get DSP-1 out the door, it would take a back seat to that code
development.  We have at least one extra TMS320C10 board, if it magically
appeared on your doorstep would you try writing code for it?  I think on
this the more the merrier and I don't doubt you could, I am asking you to
gauge the amount of time you have since we have two left in the AMSAT
loaner box.
Bob



#: 73049 S17/TAPR NNC/DSP
    31-Mar-88  12:46:14
Sb: #72878-RE: HF Modem DSP #2
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366

Suits me.  My setup works better on Mode J than Mode B anyway.  Mode L may not
be in the cards for me this year... guess I'll wait and see how much fun the
rest of you guys are having! :-)

*** More ***

#: 72975 S17/TAPR NNC/DSP
    30-Mar-88  00:33:18
Sb: #72890-update
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565 (X)

I suggest that the timer chip be controled by the TMS320, and the TMS320 ONLY.
Reviewed the schematics with mike brock about an hour ago.  I realize that they
are incomplete...i don't see how the shared memory is going to work. Do you
intend a shared memory that the V40 can only access when the 320 is stopped, or
do you intend some arbitration?  If you intend the sharde mem to only allow
program downloading, and intend to do all communication via the little tiny
data latches, you might consider some way to make the programming of this
interface reasonable on the V40 side.  Possibilities include the ability of the
processors to interrupt each other, or maybe hooking those latches to DMA
circuitry on the V40!  If you've already covered this ground, excuse me.  I
entered this thread late.  If you don't want to use the int line to handle two
different interrupts, maybe use INT for the A/D, and BIO for the V40?  I've
been thinking that you might be able to eliminate the latches on the A/D/A
chip.  The A/D is buffered anyway.  The D/A unfortunately isn't double
buffered, but could probably always be written within a few instructions of the
top of the interrupt routine.  Uncertainty would only be a few processor clock
cycles.  Maybe 1us.  That's a very small fraction of baud rates of interest,
for example 9600baud = 104uS.  I can't find a maximum clock speed on the A/D
converter spec, so i'm assuming the 5 MHz number is a max.  If so, you've got
it hooked to 25 MHz/4 = 6.25 MHz.


#: 72976 S17/TAPR NNC/DSP
    30-Mar-88  00:33:26
Sb: #DSP Articles
Fm: HamNet SysOp Scott W3VS 76703,407
To: All

Check out "must reading" for this crowd in the new (March 31) issue of
Electronics magazine.  Cover story titled "Digital Signal Processing: The Chips
are Here ... but the Software Isn't!"

Scott

*** There is a reply:   73032

*** More ***

#: 73032 S17/TAPR NNC/DSP
    31-Mar-88  09:29:59
Sb: #72976-DSP Articles
Fm: Bob McGwier N4HY 74615,1366
To: HamNet SysOp Scott W3VS 76703,407 (X)

Are you telling me I could make money at this?  ;-)  I wondered why these
folks here were willing to pay me more than I was worth and the fact that
these companies that do DSP hardware are willing to give away boards to
any serious sounding group that will write code for it.
Bob

#: 73004 S17/TAPR NNC/DSP
    30-Mar-88  20:21:38
Sb: Queries
Fm: Lyle Johnson, WA7GXD 76246,565
To: Franklin Antonio

Franklin,

The AD7569 bus timing and TMS3201x timing are such that we could only hang the
7569 directly to the bus of the DSP chip if the 320 were running at about 14
MHz.  At 20 MHz, it is pretty dicey worst case, and at 25 MHz, the gods must
smile upon you from Olympus.  Hence, the latches.

The data sheet shows the 7569 with an external 5 MHz clock, but doesn't
directly specify a maximum clock.  The "free running" clock with a capacitor or
whatever shows a conversion time ration to the 5 MHz clocked version that leads
me to believe the unit can run with a 6.25 MHz clock.

The memory is accessed by the V40 by resetting the 320 to tristate its data
bus, tristating the address bus buffers, then remapping the 4k by 16 memory to
look like an 8k by 8 chunk to the V40, which then can load/unload as it
pleases.  After the V40 is done, it drops reset and the 320 starts at address 0
once more.  To use dual port memory or a bank switched area would be nice, but
adds too much in the way of $$$.  However, see the next message I am uploading
for a possible workaround.  Remember, the 320 board is intended PRIMARILY to be
a modem.  There will be a DSP 2 or DSP 3 board that will have a hotshot DSP
chip, FIFOs on the I/O ports and all the bells and whistles you could want
(well, most of 'em anyway).

I wanted to use one of the V40 internal timers to strobe the 320 analog I/O to
save money.  A simple command (BIOS-like?) could tell it to phase shift.  To
hang an 8254 on the 320 basically means to hang one on a 8-bit I/16-bit O port
and hook its address, data, and control lines to the port.  Messy, but do-able.
I'll speak to Dan and Eric about it today when we see Eric at lunch in the
hospital.  Dan also wants the timer(s) under the control of the 320 to avoid
latency problems.

I am planning on having the 320 able to hit a pair of interrupt lines from the
V40, and the V40 able to hit the INT and BIO, as well as the analog I/O able to
hit the INT or BIO. And of course, the outside world needs to be able to do the
same, as well as provide clocking to the analog stuff. Messy again, but...


#: 73005 S17/TAPR NNC/DSP
    30-Mar-88  20:22:18
Sb: #News 1 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

DSP 1 suggestions from meeting in Eric's Hospital room today:

1) Hook 8254 timer to 320.  Use a 16-bit latch on an I/O port (timer becomes
write-only).  Allows separate timers todrive A/D and D/A, or allows Franklin's
pulse swallower (but not both). Added cost approx $7 versus using timer in V40.

2) Add second AD7569 chip.  Gives Barry his diversity reception, allows outputs
from 320 to drive oscilloscope directly for "eye" pattern measurements. Also
allows something called "correlation" to be done if I remember correctly (DSP
theory is out of my league, although I bought seven textbooks on the subject
late last year.  Now, if I could only get around to reading and understanding
them...).  Cost is about $8 plus anti-aliasing filter.

3) Dan will work out cheap antialiasing filter design.  He pointed out for low
data rate applications a simple filter followed by a software four-stage FIR
filter and decimation could handle some cases.  He will investigate an op-amp
and/or switched capacitor filter approach.

(continued -->)

*** There is a reply:   73034

*** More ***

#: 73034 S17/TAPR NNC/DSP
    31-Mar-88  09:30:20
Sb: #73005-News 1 of 4
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Dan and I have been talking about the need to completely control the timers
and the phase from the DSP chip.  Glad Eric and Frankling are speaking up on
this one.  Hope Eric is feeling much better.  Tom and I talked yesterday and
he suggests that the full 16 bit ports might be "an option".  In other words
go ahead and put the traces for the stuff on the board but leave the four
chips and connectors off the unit for Joe and Mary HT.  I want that stuff
for myself and hope to provide a PC to DSP <FAST> interface out of that but
I agree that is an area that could be unstuffed to save a few bucks.  I
don't want it left out, Dan and I have already be chatting about ways to use
that for other stuff.
Bob



#: 73006 S17/TAPR NNC/DSP
    30-Mar-88  20:22:55
Sb: #NEws 2 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

4) Make provision for upper 2k words of memory to be "swappable" between a pair
of 320 boards.  Benefit is if a pair of boards are being used, one could be
dedicated to doing, say, a 512 point FFT on incoming analog stuff, then
instantly pass the data to the next processor which does some fancy filtering
or other algorithm and passes the eventual result to the V40.  This allows a
pair of 3201x processors to work closely together in tandem fashion for those
applications which may need this sort of power. We talked about dual-port RAM
(expensive) and FIFOs (expensive) as well as using the V40 DMA resources (won't
do memory-to-memory).  And of course this gets around the fact that the silly
3201x doesn't allow multiple bus masters, or even wait states and tristatable
address and control lines.  I think I have the hardware worked out for this
already as well as how to tell the processors whose memory is whose and default
properly to each having its own.  This would add about $8.

5) I am not sure if we can do all or even any of these and meet a target cost
of $200 in 100s.  I will check into it on a cost basis.  My inclination is to
do #1, provide pads and traces but not parts for #2 and, if costs permit, do #3
(have to supply the parts for this or you lose half the program memory).

My goal is to have the direct parts cost of this thing to under $200 including
case and power supply.  It will be a squeeze.  If this cost is unrealsitic,
please tell me why and by how much!

(continued -->)

*** There is a reply:   73035

*** More ***

#: 73035 S17/TAPR NNC/DSP
    31-Mar-88  09:30:31
Sb: #73006-NEws 2 of 4
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

I support your conclusions in #5 altogether.  These are very nice things to
have and I will want all of them, but Joe and Mary Computer HT, OUR TARGET
FOR THIS, wants their PK-232 and not super fast FFT transfer.  I want to do
the second engine as much as anyone (remember the hollering back in
December?, sheesh) but we have a target, lets keep our navigation and
control systems on the original target.  I support making it possible for
Dan, Eric, Tom, Phil and Lyle to be able to add these things themselves but
they are dead weight ($$$) for the vast marjority of the folks.
Bob



#: 73007 S17/TAPR NNC/DSP
    30-Mar-88  20:23:32
Sb: News 3 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Remember, we want to get this technology into the hands of Everyham.  At the
same time, this is a unique deive that can much more than a multi-mode
controller.  And, as a multi-mode, it should be able to beat the pants off of
any other unit out there.

6) We also discussed the follow-on high-performance board and thought it best
to postpone those discussions until this one is in the bag.  The thoughts were
that the 1st cut at the 2nd project would be an IBM PC plug-in card, and things
we will want may not fit in to the philosophy of the current unit. Nonetheless,
I think there may be a very valid reason to want the higher horsepower DSP unit
on the V40 for communications applications, and am designing the V40 to at
least support the host interface of the DSP56001 as well as the 3201x.  By
bringing the V40 bus signals and some decode signals out as well as some
decoded ports, it should be possible to glue most any DSP chip to the V40.

Other developments:

7) The DSP56001 is in fact available for $56 in a "SLAM" package.  This is a
new Motorola high-density package and the price incentive is to try and get the
package established since the DSP9600x will use this package.  I am now seeking
details from Motorola on the package, as well as if Mot has a long-term
commitment to support the 56001 in this package.  If so, it is a CHEAP way to
provide an upgrade path for the DSP 1 system.

(continued -->)


#: 73008 S17/TAPR NNC/DSP
    30-Mar-88  20:24:04
Sb: #News 4 of 4
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

8) I received four (4) each TMP320C15 samples today.  They are 20 MHz parts,
and the local TI factory guy is under the impression that the 25 MHz parts
aren't available as samples yet.  He will check with Houston tomorrow.  If 25
MHz is available, we can swap the 20 MHz ones for the faster ones.  Meanwhile,
it may be that one or more of these parts will work at 25 MHz at room temp. Are
the Delanco-Spry boards socketed?  (I can't believe they wouldn't be, no one is
THAT tacky!)  If so, it should be easy to test.  I will have better word
tomorrow on the 25 MHz issue.

9) I plan to spend some (but not ALL) of the next few days working on the 3201x
schematic for more detail and get the V40 schematic and the power supply and
miscellaneous circuitry schematic in good enough shape to pass them out. I
still need feedback.

Lyle

*** There is a reply:   73036

*** More ***

#: 73036 S17/TAPR NNC/DSP
    31-Mar-88  09:30:38
Sb: #73008-News 4 of 4
Fm: Bob McGwier N4HY 74615,1366
To: Lyle Johnson, WA7GXD 76246,565 (X)

Yes they are socketed.  TI is <VERY> conservative.  We allowed David to make
severe tests on TMS320C10-20's in the 25 Meg boards.  They worked out with
no problems.  We can't afford to test each and every one we ship, so this
will be okay for the prototypes but not the kits.
Bob

#: 73050 S17/TAPR NNC/DSP
    31-Mar-88  12:47:35
Sb: HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: DSP'ers

Let me throw out a few numbers for HF modems for discussion, starting with the
basic Mark I version, which is a better mousetrap for 300 bps.

Modulation will be M-ary, or more generally, (M,N)-ary FSK, which we define to
mean M possible frequency choices, N of which are transmitted at a time.  To
beat the intersymbol interference caused by multipath, we need the symbol
length to >> the multipath spread, which is typically 1 - 3 ms, and seldom
exceeds 5 ms. The figure of 20 ms mentioned here previously looks like a good
choice, so the baud rate becomes 50 baud.  The minimum spacing between tones
that allows them to be orthogonal is then 50 Hz.  We need to transmit 6
bits/baud to get 300 bps.  Straightforward M-ary (N = 1) would then require 64
tones and a bandwidth of about 64*50 = 3200 Hz, so we can discard that
possibility.  If we let N = 2 (two simultaneous tones), the picture becomes
much brighter.

We can now make M as low as 12, and still get 300 bps.  For (12,2) FSK, there
are 66 possible combinations, so we could choose 64 of them to encode the 6
data bits.  Disadvantages: there is no straightforward mapping of the 6 data
bits into the 64 tone pairs, so a table lookup would have to be used for both
modulation and demodulation; and the bandwidth of about 600 Hz is a bit much
for most CW filters.  The first problem could be overcome by going to a (16,2)
scheme and simply letting the first 3 bits select one of the lower 8 tones, and
the second 3 bits select one of the upper 8 tones, at a cost of increasing the
bandwidth to 800 Hz.  (Question: is it worth worrying about using CW filters,
since most folks use transceivers that, unless modified, don't allow you to use
the the CW filter for receiving when you're transmitting in SSB mode?  My
impression is that most HF packet ops use SSB filters, together with IF shift
and width controls, rather than CW filters when receiving).

    [cont'd in next message]


#: 73051 S17/TAPR NNC/DSP
    31-Mar-88  12:48:39
Sb: HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: DSP'ers

How about N = 3?  The minimum M then becomes 9; a (9,3) encoding offers 84
different combinations.  Again, the mapping is not straightforward, but we get
the bandwidth down to 450 Hz.  Another advantage is that we would have a
straightforward route available to get to 1200 bps, since four adjacent (9,3)
modules (12 simultaneous tones) would occupy 1800 Hz, fitting comfortably into
the passband of a typical SSB filter.

Another point to consider: although the long symbol length protects against
ISI, the FSK signal is still susceptible to selective fading.  If multipath
produces a notch that lands on one of our tone frequencies, we's gonna get bit
errors.  The best protection against this is diversity.  It would be great if
everyone could have space or polarization diversity, with two antennas and two
receivers, but that's not a realistic expectation, and anyway, we not be able
to cram the dual modem and diversity combining required into one TMS32010/15.
With the "modular" approach mentioned above, we can use the added modules to
give us in-band frequency diversity instead of a higher bit rate, e.g., 600 bps
dual-diversity in 1800 Hz.

Time to pause to catch my breath and QRX for comments, flames, etc.  We need to
settle on a basic modulation scheme so that we can determine the sampling rate,
size of FFT required, and so on, and get some real coding started.

Barry

#: 73052 S17/TAPR NNC/DSP
    31-Mar-88  14:18:54
Sb: #73031-#RE: HF Modem DSP #2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

What was that line of Phil's... "Have board will write code..."

*** There is a reply:   73121

*** More ***

#: 73121 S17/TAPR NNC/DSP
    01-Apr-88  11:52:57
Sb: #73052-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Good Tom and I had talked it over and thought you might be interested.
I am glad you are.  Your stuff is just terrific.  I wish we had spent more
time on the presentation as you have but with the DSP code running on the
DSP board, with your code doing a lot of the grunt work on the PC it will
make a smashing package.  PHIL:  The code is in ~w3iwi/nkfdemo.arc on your
sun.  Tom ftp'd over after calling me five or six times telling me how
wonderful it was.
Bob


*** More ***

#: 73120 S17/TAPR NNC/DSP
    01-Apr-88  11:52:48
Sb: #73049-RE: HF Modem DSP #2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

The Mode L transponder is much better than the one on Oscar 10.  The better
features are: it is 250 Khz rather than 800 Khz, it has a much better front
end (better noise figure, etc.).  These features and others make it possible
to take a single loop yagi with 10 watts and get better signals (quieter
bands, etc.) than we had running 1 KW EIRP on Mode B on Oscar 10.  It will
be rather exciting.
Bob

#: 73088 S17/TAPR NNC/DSP
    31-Mar-88  22:20:59
Sb: update again
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

TI factory offical word is that the 25 MHz 320C15 won't hit production until
4th quarter and won't sample until 3rd quarter.

I am working on the gp-cpu ("TNC 3") part of the design while I await further
feedback on the DSP portion.  I have already made an alternate DSP schematic
incorporating most of the features mentioned here yesterday (8254 on DSP board,
swappable upper 2k words, second analog I/O port).

After I do a careful pricing of all this, we'll probably all faint.  I have to
keep reminding myself that the DSP card is to replace an Exar 2206/2211 and the
gp-cpu to replace the digital part of a TNC 2. When I think in those terms,
lots of the bells seem to be less important...

Lyle

#: 73099 S17/TAPR NNC/DSP
    01-Apr-88  01:09:26
Sb: #73004-Queries
Fm: Franklin Antonio, N6NKF 76337,1365
To: Lyle Johnson, WA7GXD 76246,565 (X)

Ok on the bus timing reason for the latches.   I called Analog Devices today.
(called the Mass. # on the data sheet)  Spoke with Beth Harwood in Applications
Engineering.  Pointed out to her the lack of a max clock spec on the 7569.  She
said they intended 5MHz to be a max.  I pointed out the "internal clock" graph
on pg 9, which implies higher speed operation. She said "hmm".  Said she'd get
back to me.


#: 73105 S17/TAPR NNC/DSP
    01-Apr-88  04:08:31
Sb: #Schematic part 1
Fm: Mike Brock WB6HHV 76246,546
To: Lyle, DSPers

Lyle,  I got the schematics and have been looking them over.  It looks
like there is some detail to fill in still.  First some general comments.

12 bit vs 8 bit ADC/DAC.  The most straight forward way to deal with this
is to ask the SW developers with code running in the DSP boards how 8 bits
would fair in their applications.  Something as straight forward as masking
the LSBs out of the 12 ADCs and testing could give us some valuable insight.
I sure like the simplicity of AD7569 and I think we can use it but real data
would be nice.

If we do the ADC sample clock phase shifting at all on this board it really
should be on the 320.  I think the latency thru the GP would eliminate any
advantage that the shift would have given.  What I'm saying is put the
counter/timer phase shift thing on the 320 or don't use it.  In this "simple"
version we could most likely do without the facnyness.  The ADC is fast enough
to oversample and then pick and choose which samples are optimum. Of course
there could be a problem with 320 speed with this technique.  I've done some
playing with Franklins concept of phase shifting with the 8254.  It looks
like the basic circuit can be done with the 8254, a 74x00, and 74x74, and
one inverter.  A strobe output would be required to tell the ckt to shift.
This list of parts doesn't include the buffers to make the 320 happy.
The phase shifter really only needs two of the three timers so the other
one could be used for the DAC assuming there is no need to shift this one
(I can't think of a single reason).  One other problem with this ckt is the
clock.  The fastest 8254 I've run across without looking extra hard is 10MHz.
Divide by two off of 20 MHz works great and gives 100ns resolution but dividing
by two from 25 doesn't work.  So we use the divide by 4 out of the 320??
200ns resoluiton at 20 MHz and 160ns at 25 Meg.  Are these number too strange?

*** There is a reply:   73136

*** More ***

#: 73136 S17/TAPR NNC/DSP
    01-Apr-88  13:00:42
Sb: #73105-Schematic part 1
Fm: Bob McGwier N4HY 74615,1366
To: Mike Brock WB6HHV 76246,546 (X)

I brought the Nakamichi home (Phil has my minor player). I tried the FO-12
modem, the  Bel-202 modem, the wefax-apt stuff, all with an immediate AND
with  FF0 after in the IN from the sample and hold.  I can detect no
difference in the performance.  I attribute this tp still doint the work in
a larger dynanimc range arithmetic and to the fact that the dynamic range
out of these radios of ours is  not that great to begin with.
Bob



#: 73106 S17/TAPR NNC/DSP
    01-Apr-88  04:10:29
Sb: #Schematic part 2
Fm: Mike Brock WB6HHV 76246,546
To: Lyle, DSPers


The idea of the second AD7569 is nice but I'm starting to worry about where
to draw the line.  One of the eariler ideas was to allow multiple DSP engines
on one GP engine.  If the interface is worked out will this solve the dual
AD7569 issue?  I'm having a hard time seeing where all but a few will ever
use this feature, at least at the DSP-1 level.  Maybe the DSP-2... or am I
missing something?   Of course if there is board space left over it could
be added as an assembly option....

I'm not sure I understand the input/output port that talks to the serial
i/o's of the GPs 8530.  Is this going to be used to pass data back and forth
between the GP and the DSP?  The only real need for I can see for this is
to support the modem disconnect in an existing TNC.  I'd suggest eliminating
the serial interface and using the parallel interface to communicate between
the DSP and GP.  If the modem disconnect is desired it could probably be
handled by the 16 bit general purpose I/O.  Of course running with the modem
disconnect and a TNC will require some sort of PROM for the DSP code.

Speaking of the modem disconnect and TNCs; I've been talking with a few
folks out here about the DSP project.  Most of them are under the impression
that it is a modem that attaches to the modem disconnect port of a standard
TNC (like the PSK modem) and that it will have switches of some type for
changing functions so they can have an FSK modem, a PSK modem, a JAS modem,
a RUDAK modem, a PACSAT modem, etc.  This is the impression that we left
people at the TAPR meeting.  Frankly I was a bit suprised to see how strongly
the disconnect idea was supported.  I think it is the "low cost ham" syndrome
that we are looking at again.  Anyway this derserves some thought and some
explination.  Hopefully the explaniation of the new TNC-3 approach will be in
the DSP article in PSR ( I confess I haven't read it yet).

*** There is a reply:   73137

*** More ***

#: 73137 S17/TAPR NNC/DSP
    01-Apr-88  13:01:05
Sb: #73106-Schematic part 2
Fm: Bob McGwier N4HY 74615,1366
To: Mike Brock WB6HHV 76246,546 (X)

It is not explained in the article I submitted as we are still deciding what
it is ourselves.  I would look at it as we have had a better vision of where
the real first product out to be placed and what it should look like.  This
module isn't limited to one manufacturers box, it isn't limited to being
only a modem for a tnc.  It is even just a switch of boards if we do it
right to get DSP-2 (God, I can't believe the Motorola prices!).  I also
don't understand the serial transfer between the DSP and the V40, since the
only paths I see use for are the parallel and the 85C30.  The SCC is really
a neat chip and will do so much of the work for us that this thing will be
able to do many more telecommunications of bauded signals that we would have
a tough time doing otherwise that the 85C30 and the V40 are justified on
that almost alone.
On the being able to use the DSP chip to adjust the phase of the sampling
clock, if it is really just too expensive because of the TMC320C1X
architecture (or lack thereof) then so be it.  It will be the difference in
being able to do a better than hardware implementation of the K9NG modem
since I will not be able to sample synchronously and will have to so
oversample that I will probably not get all of the necessary goodies in the
code to beat the hardware.  Even with 4 watts, MartinSat is gonna need some
nice radios and modems to make it really useful.  I would like us to at
least go through the motions of getting this put in before we throw it out
because it is too costly.  All the extra connectors etc. are what aren't
justified to me on the generally available product but I still want the
option of adding all that myself.
Bob



#: 73107 S17/TAPR NNC/DSP
    01-Apr-88  04:12:34
Sb: #Schematic part 3
Fm: Mike Brock WB6HHV 76246,546
To: Lyle, DSPers

One thing that seems to be missing is the radio interface.  What about
things like PTT, transmit timeout timers, level adjusts to allow the use
of radio xyz.  If this is standalone we can't expect the TNC2 to handle this.
Other controls like UP/DOWN would be nice.  I expect that most of this is
driven by the 16 bit input and output port but I also expect that additional
interface circuitry is required to communicate with a radio.

Getting more directly to Lyle's list of questions/comments:

1. PAL operation and word vs byte.  OK Lyle I'll trust you that it works.
   I'm still leaning to 16 bits, though.  The processor chip cost is a wash.
   Additional cost for 16 bits would be an extra EPROM site on the GP, maybe
   an extra RAM site depending on the amount of RAM (one or two or ? chips),
   and possibly an extra data buffer for the other half of the word.  Besides
   it actually might save some logic on the DSP engine.  I like to go fast
   so maybe these comments aren't valid on this project but I really don't
   want to go on to super wizz bang DSP-7 with an 8 bit bus GP engine.

2. The 16 bit input port.  I'm assuming that this is a general purpose
   input.  Using latches to resolve metastable conditions on async inputs
   is definatly the right move.  On inputs I would definitly put some sort
   of pull up resistor at a minimum.  Something like 10K would be fine. I
   really don't want to see CMOS inputs ( or any input for that matter) float.
   Of course if we really want to overkill this we could add some RF
   filtering to keep RF out and noise in.

3. The 16 bit output port.  I'd leave these at registers.  I don't see any
   reason to have the potential of unstable line being driven to the outside
   world.  Termination is probably not as important here as long as the
   enable lines are always on.  If they can be turned off as sort of indicated
   in the schematics they we probably want the 10K pull up again.  The
   overkill comments in 2 apply here.

*** There is a reply:   73138

*** More ***

#: 73138 S17/TAPR NNC/DSP
    01-Apr-88  13:01:12
Sb: #73107-Schematic part 3
Fm: Bob McGwier N4HY 74615,1366
To: Mike Brock WB6HHV 76246,546 (X)

I bet the control of the world is on the V40 board where it should be but
will await Lyles say on this.  I too am worried about the 16 bit versus 8
bit issue and wonder exactly what went into the decision process, maybe we
can illicit a comment or two on that.
Bob



#: 73108 S17/TAPR NNC/DSP
    01-Apr-88  04:14:29
Sb: Schematic part 4
Fm: Mike Brock WB6HHV 76246,546
To: Lyle, DSPers

4. 8 bit/16 bit GP comm port.  My first shot here is to use 8 bits. Making
   the rash assumption that we are dealing with characters the 8 bit port
   makes life much simpler; it gets rid of the dangling byte problem (is
   the last transfer one character or is it really two?)  This problem has
   been known to cause severe confusion.  I've actually seen the hardware
   provided to do this and then watched the software avoid it just to
   maintain santity and we need to conserve as much of that as possible!
   What would be nice is to set up a couple of DMA channel to deal with
   this interface on the GP side.  The 320 would poll ( actually control
   the xfer) and the GP would DMA.  The 320 could then get faster service
   for buffer xfers.  The data rates we are talking about aren't that high
   so DMA isn't a requirement; interrupts would do.  What I'm thinking about
   is the general interface for DSP-7.  If 16 bits are really desired I'd
   implement it as two seperate 8 bit ports.  That way one could act as the
   transfer channel and the other could be a command/status port which could
   be useful to define the type of xfer that was occuring (control vs data
   vs initialization, etc) as well as xfer stages and error conditions.

5. Filters.   Put Dan and Eric on this one.  Do we want to add some level
   adjustments here?

6. The I/O space as currently shown in the schematics is only half used.
   If it stays that way the two 138s could be combined into a single 139.
   I think we'll find uses for the extra I/O strobes though so don't
   combine them yet.


#: 73109 S17/TAPR NNC/DSP
    01-Apr-88  04:15:36
Sb: #Schematic part 5
Fm: Mike Brock WB6HHV 76246,546
To: Lyle, DSPers

7. 8530 interface port, LEDs.  See my earlier comments about the 8530 port.
   Ah the LEDs.  Users love them.  It gives them some idea of what is going
   on and the positive feed back is reassuring as well as usefull for
   trouble shooting operational problems.  Now the hard part; which ones
   do we put in or do we make all of them (well maybe not power) software
   controlled?

I'm out of time tonight so this will have to be continued another day.
Keep up the good work!

Mike

*** There is a reply:   73243

*** More ***

#: 73243 S17/TAPR NNC/DSP
    03-Apr-88  02:34:44
Sb: #73109-Schematic part 5
Fm: Tom Clark W3IWI 71260,3640
To: Mike Brock WB6HHV 76246,546 (X)

Agree that we need to think about the radio connections a bit more.
UP/DN lines + PTT + key (remember CW?) require at least 4 isolated
wires.
On the timers, I would request that the sampler inputs be made available
on jumpers so that the A/D conversion could be totally paced from
an external clock.

#: 73135 S17/TAPR NNC/DSP
    01-Apr-88  13:00:31
Sb: #73050-HF Modems
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Dan believes very strongly and from experience that we MUST target the thing
for filling standard filters.  The problems of AGC, and others were at top
of his lists of reasons why.
Bob

#: 73156 S17/TAPR NNC/DSP
    01-Apr-88  20:40:12
Sb: #Hartley Transform
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Thanks to Tom for pointing out this interesting article in BYTE magazine in
the April issue concerning the Fast Hartley Transfrom.  We are almost
exclusively dealing with real signals in our applications and this makes
good use of that fact as it does not compute a complex transform and it uses
a different set of orthogonal functions to make up the orthonormal basis in
computing the generalized Fourier transform.  What the hell is Bob saying?
He is saying it looks like we can do 1/2 half as many operations and NONE of
these operations are complex resulting in another 1/2 savings in number of
multiplications and we will not be throwing away half the bins which contain
redundant information so to get the same resolution we can have take another
1/2 off the number of points needed to compute the transform to get a
certain resolution.
I have already been totally disatisfied with the FFT we were doing in our
spectral analysis programs.  After Franklin told me what he was doing in
terms of time per FFT on the PC, I knew something was dreadfully wrong.  I
first adapted David Langman's (Da Lan CO Spry) FFT which was also taken
straight out of TI's stuff and this is a straight Cooley-Tukey.  I have been
working on a Danielson-Lanczos FFT implementation which should by us back a
factor of 8-10 in speed over the current FFT we are doing.  This is because,
we can't do a straight line FFT (don't have enough memory) so we need to do
a looped FFT.  The Danielson-Lanczos (done years before Cooley was born)
does the bit reversal permutation first (So does the Fast Hartley), then
computes the sin cos terms ONCE in the outer loop (so does the Fast Hartley
with the new functions) and then in the inner loop, the trig functions are
computed by a recurrence relation (so does the fast Hartley) which in the
Fourier case, is really just a derivative of sums of angles formulae.  The
bottom line is that we can do probably 10 times faster than we are doing now
with complex Fourier transforms to 40-50 times faster with real only


*** There is a reply:   73217

*** More ***

#: 73217 S17/TAPR NNC/DSP
    02-Apr-88  18:47:01
Sb: #73156-Hartley Transform
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Bob, you should read the following article... "Real-Valued Fast Fourier
Transform Algorithms" by Sorensen et al in IEEE Transactions on Acoustics
Speech & Signal Processing, June '87. These fellows have worked out well
trimmed RV-FFT algorithms, and compare them with the Fast Hartley Xform.  They
conclude their RV-FFT is faster. I agree.  My integer FFT on the PC is based on
the model in this article. Same guys published an article same journal Oct '85
on implementation of Fast Hartley.


#: 73157 S17/TAPR NNC/DSP
    01-Apr-88  20:40:54
Sb: #Hartley I and Plans
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Hartley transform, which still allows us to compute a power spectrum which
is what we need to do (1) weak signals with the coherent-noncoherent
averaging scheme Tom and I pulled with the EME "humps", (2) the HF modem
work Tom, Barry, and I have been discussing here, and (3) the fantastic
spectrum analyzer that we will have after I put this new FFT into Franklin's
"Outer Loop" code which is astounding to say the least (wish I had a mouse
Franklin, maybe I will break down and get one).  It is about 100 dB
improvement in presentation over the kludge that Tom and I hacked together
for our stuff.  I really like the cepstrum, do you guys do any speech work
Franklin?  I am getting the coding fever again.  I will be spending the
six to eight weeks following the trip to Europe working in D.C. during the
week and will be doing a lot of coding work with Tom.  Then it will be off
to California to L.A. for the summer. I think I will be staying in Redondo
Beach but the i's need dotting and the t's need crossing there with the
realtor.
Bob


*** There is a reply:   73218

*** More ***

#: 73218 S17/TAPR NNC/DSP
    02-Apr-88  18:50:14
Sb: #73157-#Hartley I and Plans
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Name brand mice now available for under $100., and clones under $50. I swore
i'd never buy one, 'til i ran codeview.  Scroll bars appeared on the screen,
and i did the natural thing.. i reached for a mouse.  Except.. i didn't own a
pc mouse!  Great mental anguish over the fact that i could be so easily fooled.
Bought mouse next day.

*** There is a reply:   73244

*** More ***

#: 73244 S17/TAPR NNC/DSP
    03-Apr-88  02:34:57
Sb: #73218-#Hartley I and Plans
Fm: Tom Clark W3IWI 71260,3640
To: Franklin Antonio, N6NKF 76337,1365 (X)

Problem with mouses (I'd say meese, but that has a bad connotation
in the DC area right now) is that they chew up ports. The %$#@*&^&%
PC spec with only 2 serial ports is a pain! I thought the solution
was a buss mouse, so I tried one this part week. First tried IRQ5,
but that clobbered the Ethernet board, IRQ 3&4 were taken by the
serial ports. So I tried IRQ2 which was a disaster since the AT (and
most 386's) multiples a bunch of interrupts onto IRQ2. After these
disasters I pulled the mouse out of my 386, and am still rodentless.

*** There is a reply:   73281

*** More ***

#: 73281 S17/TAPR NNC/DSP
    03-Apr-88  16:32:38
Sb: #73244-Hartley I and Plans
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640 (X)

You're right about serial port limitations being a problem. I solve that with a
giant switch box here.  The AT doesn't ever want to talk to the modem, mouse,
and Macintosh simultaniously, for example, so i share same port.

#: 73190 S17/TAPR NNC/DSP
    02-Apr-88  04:58:58
Sb: #DSP articles
Fm: Bob McGwier N4HY 74615,1366
To: ALL

Thanks to Scott's prodding, I looked in a few magazines and found many
articles in the past few months on DSP and DSP hardware.  It is clearly not
only the darling of this group.  I thought some neat figures might interest
you.  From Electronic Design, February, there are four full pages of DSP
boards listed and their capabilities are listed.  Some figures from these
pages, which appear to be a fairly comprehensive listing of the DSP boards
available.
There is one board carrying the TMS320C15, 20 Mhz, and it is available in PC
Bus form, from Atlanta Signal Processors, the 320/PC-15 (they also have a
320/PC-10 and PC-17).  This uses the PC to do the V40 work and of course it
has no 85C30 to smooth the way for bauded data (pun intended).  It has 12
bit A/D and D/A converters, 4 Kwords dual ported.  They are kncking back
$2195 in quantities of 1 for these boards.  They have daughter boards for
the 10, 17, and the 25 to replace the processor on this main board.  They
are $895 to $1295 additional.  The least expensive PC board is David's Model
10 board and it is listed at $695 for 1.  The cheapest PC bus board with a
TMS320C25 in it is $2595 with 16 bit A/D with 8K data and 8K program.
There is not one board at this time using the DSP56000 (they just had the
thing ridiculously priced until recently) and their is NO DSP product listed
here with a host processor on it.  The cheapest thing in the whole bloody
list is Davids board.  I think we might just sell a few of these widgets.
If we do a DSP56000 follow on, the only competitor there is a new product
done for Motorola, called the EXP which AMSAT owns two of, and Motorola says
they will be marketed for $5500 a piece.  No host processor or SCC.
Bob


*** There is a reply:   73219

*** More ***

#: 73219 S17/TAPR NNC/DSP
    02-Apr-88  18:59:38
Sb: #73190-#DSP articles
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

Headline in EDN NEWS March issue is a board for IBMPC containing an AT&T DSP32
chip with 32K ram and A/D, D/A for $695.  Nice price. Manufacturer:
Communications Automation & Control, 215-776-6669. The article mentions two
versions of the board.  Version described above they claim "8 MFLOPS".  Faster
(<$1500, and not available yet) version is claimed "25 MFLOPS".  They don't
list clock speeds.  They list a benchmark of 3.3ms 1024-pt complex FFT on the
fast board.  I guess that would mean 10.3ms on the slow $695. board?

*** There is a reply:   73262

*** More ***

#: 73262 S17/TAPR NNC/DSP
    03-Apr-88  12:28:26
Sb: #73219-DSP articles
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Interesting.  I will check into that.  The article in E D didn't have any
DSP-32C boards and no DSP56000 boards.  I think folks are a little
conservative since the ridiculously high prices are caused by them being put
out by somewhat small venture companies who have to recover the large
nonrecurring engineering costs and this leads to small volume.  The only
companies I recognized in the whole article as being larger than tiny were
Analog Devices and Burr-Brown with Analog Devices board at $5995 for the
ADSP-2100 (8 MIPS) and Burr Brown had a DSP-32 (not 32C) board for $995.
The 32 is the 8 MIPS and the 32C is the faster one that no one can get in
large enough quantity to go to market with.  It is 32 Bit Floating Point
processor so dynamic range is not the problem.  The "instruction set" looks
and feels like C, so I bet a C compiler would be easy to write for it.  I
have the manuals from the fellow who works at AT&T for the head of their DSP
microprocessor division (NN2Z, co-author of BM in Phil's TCP-IP) and he is
running interference for my request for "donations."  ;-)
Bob



#: 73191 S17/TAPR NNC/DSP
    02-Apr-88  04:59:05
Sb: Speed figures earlier
Fm: Bob McGwier N4HY 74615,1366
To: ALL

My speed improvement for better algorithms before of course was only for the
inner loops, the overhead in these programs will be just about the same.
There will be a significant speedup, on the order of going from several tens
of ms for a 1024 point derived spectrum, to between 10 and 20 ms for same.
Bob

#: 73240 S17/TAPR NNC/DSP
    03-Apr-88  02:34:15
Sb: #73035-#NEws 2 of 4
Fm: Tom Clark W3IWI 71260,3640
To: Bob McGwier N4HY 74615,1366 (X)

I really like the idea of being able to use 2 A/D converters. Barry
spoke of the desire to allow diversity, and I can think of several
applications that could be done if there were the ability to extract
the cross-spectral function. Here are a couple: (1) the ability to
measure complex transfer functions. (2) The ability to do pseudo-
random ranging to study the ionosphere. This one came to me last
nite when I was listening to 14.109 and hearing the tail-end of each
of my frames come back to me as it was bounced off the ionosphere
over the Pacific. Modern radios (like my TS940) have T/R switches
fast enough so that you can hear your own echoes! (3) the ability
of the DSP box to process the output of two receivers (with separate
antennas) as an interferometer to do accurate locations of transmitters
(DFing). Imagine being able to determine the azimuth of an illicit
station to better than one degree!
Re interrupts: The current code all uses BIO as the A/D conversion
completion flag. Since DSP code is very repetitive, it doesn't make
much sense to use the INT interrupt within a modem/filter. I see
no reason not to have the V40 dedicated to the INT interupt.

*** There is a reply:   73263

*** More ***

#: 73263 S17/TAPR NNC/DSP
    03-Apr-88  12:28:36
Sb: #73240-NEws 2 of 4
Fm: Bob McGwier N4HY 74615,1366
To: Tom Clark W3IWI 71260,3640 (X)

Lyle seems to be working it up so that you can put two complete DSP boards
in the DSP-1 so that diversity receivers and higher speed modems with
Adaptive Equalization (and a bigger price tag) should be very do-able.
I can think of a ton of scientific experiments that a hand full of us will
like to do with these boards.  I think I am going to have to break down and
get some HF gear, but not until my 56KB stuff is on the air and I fully
"suited up" for Oscar-13.
Bob



#: 73241 S17/TAPR NNC/DSP
    03-Apr-88  02:34:21
Sb: #73008-News 4 of 4
Fm: Tom Clark W3IWI 71260,3640
To: Lyle Johnson, WA7GXD 76246,565 (X)

Send one of the 320C15's when you can and I'll make sure there are
no 'gotcha's with it.


#: 73242 S17/TAPR NNC/DSP
    03-Apr-88  02:34:35
Sb: #73051-#HF Modems, Part 2
Fm: Tom Clark W3IWI 71260,3640
To: Barry McLarnon VE3JF 71470,3651 (X)

Full in-band diversity (i.e. sending each bit twice) has a problem.
If the two bits agree, all is well and good. But if they disagree,
who is right? The naive solution is to use 3-way redundancy and do
a majority vote, but the price of the improvement is a tripling of

the bandwidth required, and a 9x increase in xmtr power (remember
our peak-to-average discussions of a couple of weeks ago?) required
or an 9 dB decrease in s/n with a fixed xmtr power level. Looks to
me that rather than sending multiple replicas of the same signal,
some form of convolutional encoding is a much better approach. Example:
If 8 bits were required in the data, then encoding 12 bits allows for
a suck-out on any one channel with no loss of performance (4 bits
will fully correct one bit error in an 8 bit field).

*** There are replies:  73294, 73308

*** More ***

#: 73294 S17/TAPR NNC/DSP
    03-Apr-88  17:55:38
Sb: #73242-#HF Modems, Part 2
Fm: Bob McGwier N4HY 74615,1366
To: Tom Clark W3IWI 71260,3640 (X)

I tend to agree that "in band" diversity will not pay us as much as encoding
in SNR.  It will also certainly be simpler.  The diversity receiver is a
good idea and will be one heck of a nice experiment.  I would like to see us
come up with the most optimal scheme we can for a ham with one radio and one
DSP board.  We can afford to run quite a long constraint length and do a
Jellenick stack algorithm sequential decoder with soft decisions and I am
sure this will put to severe shame diversity schemes that use one radio one
antenna one DSP board (i.e. the most likely shack in a year ;-).
Bob


*** There is a reply:   73315

*** More ***

#: 73315 S17/TAPR NNC/DSP
    03-Apr-88  21:02:30
Sb: #73294-#HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Bob McGwier N4HY 74615,1366 (X)

On fading channels, a tremendous gain is made by using soft decisions, and SOME
coding.  A little more gain can be had by using more elaborate coding. Don't be
fooled by the AWGN channel coding-gain comparisons. For example, on a rayleigh
channel, you can gain something like 40 db just by going from simple binary FSK
to a [24,12] Golay block code. You can theoretically do another few db with a
better code.  What's the use? What you really want is that first big chunk.



*** There is a reply:   73346

*** More ***

#: 73346 S17/TAPR NNC/DSP
    04-Apr-88  18:35:32
Sb: #73315-HF Modems, Part 2
Fm: Bob McGwier N4HY 74615,1366
To: Franklin Antonio, N6NKF 76337,1365 (X)

Right, we have only been talking seriously about doing Golay or Hamming etc
and not convolutional codes on HF anyway.  Just being provocative ;-)
Don't think I have seen anything less Gaussian than 40 meters in a long
while ;-)
Bob


*** More ***

#: 73308 S17/TAPR NNC/DSP
    03-Apr-88  20:45:25
Sb: #73242-HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640 (X)

Tom, there's absolutely nothing wrong with sending each bit via two different
channels, whether by frequency or time or space diversity.  The "problem" you
describle, "what happens if we read one as a one, and one as a zero?" is a
non-problem.  The correct solution is to combine SOFT decisions from the two
receptions of the bit.  In this case, with no coding, the louder bit wins.


#: 73245 S17/TAPR NNC/DSP
    03-Apr-88  02:35:09
Sb: #Dayton?
Fm: Tom Clark W3IWI 71260,3640
To: DSPers

I think we need to have a meeting of the hard core DSPers to discuss
such things as algorithms, coding standards, hardware, plans, ideas,
etc. Dayton always seems to draw a big bunch of folks, so it might
be an idea to plan a gettogether somewhere. I'd like to ask who all
is coming to Dayton and if you'd like to try to meet sometime for
a few hours.
73, Tom

*** There is a reply:   73309

*** More ***

#: 73309 S17/TAPR NNC/DSP
    03-Apr-88  20:46:35
Sb: #73245-Dayton?
Fm: Franklin Antonio, N6NKF 76337,1365
To: Tom Clark W3IWI 71260,3640 (X)

I am planning to attend Dayton, but haven't done any of the planning (ie
travel, schedule, etc) yet.


#: 73251 S17/TAPR NNC/DSP
    03-Apr-88  03:46:01
Sb: Varous 1 of 2
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

I appreciate the comments that have been coming in!

While there are good arguments for not having options, and some features will
probably only be used by a few folks, I am inclined to include pads and traces
to support the experimenters.  The TNC 1 had a wire wrap area that wasn't used
by too many folks, but it was used.  A 16-bit parallel port for input and
output, and a second analog channel, and swappable memory may not be used by
too many, but it may not cost us much to include it.  I think we can do the
traces and pads and only a couple support ICs for the swappable memory (1/2 to
be exact) and only add maybe $5 total to the thing...

I will look for Mike's pulse swallower circuit to include in te next round of
circuits.

When I think about the V40 vs V50 issue, I keep telling myself this is a TNC,
not an IBM PC.  I think for a communications application, and memory loading of
the 3201x, the V40 should suffice nicely and keep the costs down (remember,
this is replacing a Z80).  For the high bandwidth, graphics display whiz bang
applications, perhaps we can use the DSP 2 board (PC plug-in for development
use, and a product in itself) and the DSP 3 version of whatever processor winds
up in the DSP 2 can be married to the V40, again for communications
applications.

I am putting the schematic on three sheets.  I have planned on putting the DSP
stuff on one sheet (and one baord) and the V40 on the second sheet with its
digital functions.  The third sheet is power supply, front panel,
interconnections and PTT etc.

I figured on two radio ports (VHF and HF?) although more would be nice, but...
Watchdog timers on the PTT lines (it can be set for a few tens of seconds -
long enough to send RTTY art, I guess) based on a CD4528 rather than the

(continued -->)


#: 73252 S17/TAPR NNC/DSP
    03-Apr-88  03:46:54
Sb: Various 2 of 2
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

74HC14 used in the TNC 2 which can fail in the wrong state if the timing
capacitor goes leaky.  "Cathode" and "grid-block" CW keying (is this needed on
both ports?).  UP, DOWN, and PTT via VN10 type VFETs (again, is this needed on
both ports?).

I thought the PTT and DCD lines should drive LEDs directly.  Should we assume
that all applications will use a terminal or computer and eliminate some of the
switches on the front panel (saving $$) or should we include a multiposition
selector switch and reset button for loading applications?

Should the power supply use a charge pump or are there cheap, easily produced
transformer based switchers we can make for under $5 to give us the voltages we
need (I am looking but the $5 keeps getting in the way).

Jumpers are cheap, software controllable selectors less so.  On the other hand,
do we want to have applications code that requires setting various jumpers to
reconfigure the box?  INT, BIO, clock sources, pulse swallower versus
independent clocks, external 320 master clock versus on board clock, are a few
of the lines that come to mind.

I am planning of trying to get the 8530 and V40 to play the DMA transfer game
on both ports (which takes away the internal UART from the V40).  Maybe one
full-duplex channel on the 8530 under DMA control is enough?

If we use the internal UART on th V40 (I favor doing so) it will be a
three-wire interface -- no hardware handshaking unless we dedicate some
parallel port lines to this function (do-able but a little messy in the
software).

Lyle

#: 73295 S17/TAPR NNC/DSP
    03-Apr-88  17:55:49
Sb: RUDAK
Fm: Bob McGwier N4HY 74615,1366
To:  71260,3640 (X)

Indeed in Figure 2 on page 103 of the 6-th Networking conference proceedings
on the RUDAK user terminal there are two demodulators, 400 bps Bi-Phase and
1200 BPS NRZI.  Damn!  We just let it go right over our heads.  Tell you also
that I let go over my head and should have realized.  It is going to be a
pain in the royal ass to get ready for RUDAK since we will have to have a
special exciter just for it.  I didn't realize that it was Manchester
BPSK and the spectrum is 1500Hz wider than any SSB radio I would own ;-).
I am making that LOUD and clear in a message to section 5.  If folks want
to do packet in a hurry and cheaper than a lot of bucks then the PSK modems
are THE way to do it.
Bob



#: 73296 S5/Amateur Satellites
    03-Apr-88  17:56:09
Sb: #RUDAK Uplink
Fm: Bob McGwier N4HY 74615,1366
To: ALL

I am getting a bad feeling that folks don't really understand what it will
take to use RUDAK and why I have been stating in the strongest possible
terms that the TAPR PSK modem used in the linear transponder will be the
big hit on OSCAR-13 (Phase III C).
RUDAK uses 2400 BPS Bi Phase PSK on the uplink.  This implies that the
spectrum of the modulated data will have a frequency occupancy between the
first zeros of its unfiltered response of 4800 Hz.  What does all that
gobbledy gook mean?  It means that your SSB radio would have to have filters
that allowed at least 4800 Hz wide stuff through it.  As most of you know,
the filters in a typical SSB radio cutoff at around a couple of hundred Hz
on the lower edge and in the 3300 Hz range on the upper edge and further,
the response is anything but flat in between.
YOU WILL NOT BE ABLE TO USE YOUR SSB RADIOS WITH RUDAK, No way, no how
without modification.
You will have to set up a special RF modulator, probably in the 28 Mhz
or 144 Mhz range and use a transverter to kick it up to 1269 Mhz.
I hope you get the ($$$$$$$$$) picture.  You will have to have an exciter
that will drive the transverter that you were already going to use for
mode L (that is if your going xvtr route). I'm not discouraging the serious
experimenter, but this is not for the casual satellite user, much less the
casual packet user.  On the other hand, with the TAPR PSK modem your SSB
radios will have a great opportunity of giving you much packet radio fun on
our new satellite, which is just a few weeks away from launch (last week
in MAY!!)
Bob N4HY


*** There is a reply:   73319

*** More ***

#: 73319 S5/Amateur Satellites
    03-Apr-88  23:46:45
Sb: #73296-#RUDAK Uplink
Fm: JACK E. DAVIS - WA4EJR 72356,441
To: Bob McGwier N4HY 74615,1366 (X)

Thanks for the info Bob. Sure makes me wonder what the designers were thinking
about when they came up with the RUDAK idea. You got any ideas or experience
with any of the xvtrs advertised in the magazines? I hope someone has an
affordable way of getting from 144 exciter to 1269. Everything I have seen is
well over $500. Then there is antenna and feedline to contend with....boy you
sure are right on the ($$$$$$$$) situation.

73, Jack



*** There is a reply:   73347

*** More ***

#: 73347 S5/Amateur Satellites
    04-Apr-88  18:35:42
Sb: #73319-RUDAK Uplink
Fm: Bob McGwier N4HY 74615,1366
To: JACK E. DAVIS - WA4EJR 72356,441 (X)

Jack the real pain is you have to modulate the bits somewhere, and this
means you need to build an exciter or do some fancy footwork at 2 meters
before you go into the 1269 upcoverter.  I just knew from too many
conversations (including your messages) that folks had not had anyone take a
brick in the face approach to "here is what you need" and I didn't think a
lot of disappointed folks was in our best interests.  It is going to be a
TERRIFIC satellite, and The JAS modems are going to make packet a real thing
on this bird.
Bob

#: 73404 S17/TAPR NNC/DSP
    05-Apr-88  15:17:35
Sb: #73242-HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Tom Clark W3IWI 71260,3640

You're thinking in terms of majority-logic decoding and hard decisions, but I
would do soft-decision decoding by simply adding the outputs of the FFT bins
which correspond to the same data bit before making the hard decision on that
bit.  Then it doesn't matter if the two bits disagree, as long as the amplitude
of the right one exceeds that of the incorrect one.  If you want to get fancy,
you can weight the bin values before summing them by an estimate of the SNR in
the corresponding bin.  Soft-decision is inherent in dual diversity.

I agree that in-band diversity is a VERY crude way of using redundancy.  Its
only advantage is that it is very easy to implement and it does work pretty
well, so we may want to use it for a KISS approach to getting something useful
on the air.  Convolutional decoders need a lot of processor resources to
implement, and I don't think they would be worth the sweat right now (very
promising for satellite channels though).  If we are transmitting n
simultaneous tones, we can superimpose an (n,k) block code to provide
redundancy, as in your (12,8) example.  That takes some crunching too, as
you've got to find the best match to the received codeword from amongst 512
possibilities.  Worth looking at though... the coding schemes do offer more
flexibility and somewhat better performance than dual diversity.  Fitting 1200
bps into 2 kHz BW, complete with long bauds, low peak-to-average ratio, AND
redundancy in the frequency domain, is a tough nut to crack, however.

I guess the reason I'm trying to steer a relatively simple, straightforward
course for the Mk 1 HF modem is that I'm harboring hopes of coming up with an
implementation that is self-contained in the DSP board and interfaces to a TNC
and radio entirely through audio connections.  This would enable us to do some
useful experimenting with the D-S board with minimal non-DSP hacking.  The Mk 2
edition would await the new TAPR engine, with the dedicated GP processor
available to do coding, new protocol implementations, etc.

Barry


#: 73405 S17/TAPR NNC/DSP
    05-Apr-88  15:18:39
Sb: #73252-Various 2 of 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Lyle Johnson, WA7GXD 76246,565

Just got the skiz... herewith a few initial comments:

U8, the 74F74, is not needed.  Retiming the BIO and INT inputs is necessary
only on the NMOS 32010; the 320C1X devices take care of this internally.

I am a little puzzled as to how sampling jitter due to variable conversion
times is avoided (as stated in sec. 14), since the BIO or INT input is still
tied to the INT output of the A/D.  However, I think conversion time jitter is
probably a non-problem with an 8-bit converter anyway.  I'm at a bit of a
disadvantage here, as I didn't get an AD7569 data sheet in the mailing, and
haven't been able to track one down locally.

I like the idea of having software-configurable switches instead of jumpers, if
the added cost is affordable.  Having to open up the box to change jumpers
really detracts from the promise of "It's Only Software", i.e., this is a box
of tricks that can do several diverse tasks in an amateur station without major
hassles.

In the same vein, there should be connectors for at least two receivers and two
transmitters, with the receive audio (+ AFC?) and transmit audio/PTT lines
separately switchable so that any combination can be selected (to facilitate
crossband and full-duplex operation).  Each audio input and output should have
its own level control.

Speaking of level controls, since setting the level of the signal into the A/D
is fairly critical, and most hams don't have scopes 'n such, shouldn't we some
sort of peak-responding level indicator, a la the bargraph LED in the PSK
modem?  Then there's the tuning indicator...

There are quite a few applications that the DSP chip could handle, once the
code is loaded, without the services of the V40.  I, for one, would like to
avoid writing V40 code in addition to DSP code whenever possible!  Having a few
uncommitted LEDs controllable directly by the DSP chip would help.

Gotta go look at your bumpf again, and read what others have posted...

73, Barry

#: 73418 S17/TAPR NNC/DSP
    05-Apr-88  20:39:43
Sb: #73404-HF Modems, Part 2
Fm: Bob McGwier N4HY 74615,1366
To: Barry McLarnon VE3JF 71470,3651 (X)

Sounds like a program plan to me!  I have been trying to get the RVFFT and
the Hartley transform coded on the DSP board before I left for the UK and I
am just not going to make it.  I have to get Solar analysis software out the
door and in the mail to Jansson for PACSAT and Phil wants my Phase III C
modem stuff and documentation (what does he think this is, a company ;-)
and I want to try and get that done by morning.
I will do the best to finish it before Dayton.  I sure wish you could make
it but understand.
Bob



#: 73447 S17/TAPR NNC/DSP
    06-Apr-88  03:33:16
Sb: #73346-HF Modems, Part 2
Fm: Phil Karn, KA9Q 73210,1526
To: Bob McGwier N4HY 74615,1366

But Bob, block codes like Golay or Hamming generally involve a hard
decision, right? I thought one of the nice things about convolutional
codes is that they work on a series of measurements of signal voltage
quantized to some reasonable number of bits, and this buys you a lot in
coding gain.

At the rates we're talking about for HF, either sequential or Viterbi
decoders should be easy to implement in DSP.  I tend to lean toward
sequential mainly to allow the use of some truly awesomely long
constraint length codes, long enough that they might extend right
through brief fades.  All you have to do is declare a time limit on the
decoding process (since sequential decoding algorithms are not
deterministic, like Viterbi).  If you run out of time, just give up and
let the other end retransmit the packet.  Hybrid FEC/ARQ!

Phil


*** More ***

#: 73446 S17/TAPR NNC/DSP
    06-Apr-88  03:32:58
Sb: #73308-HF Modems, Part 2
Fm: Phil Karn, KA9Q 73210,1526
To: Franklin Antonio, N6NKF 76337,1365

But Franklin, if you just add the two bits (softly) you might as well
just send the bit once, taking twice as long (and twice the energy) to
do it.  This is what an integrate-and-dump detector does continuously
during each bit interval.

Simply repeating bits is called "repetition coding" by the theorists.
(Ah, theorists! Where would we be without them!) But it isn't a
particularly efficient technique.

Phil

#: 73438 S17/TAPR NNC/DSP
    06-Apr-88  00:58:52
Sb: Comments
Fm: Lyle Johnson, WA7GXD 76246,565
To: DSPers

Barry's right on the CMOS 320s not needing the sync latch on INT and BIO.  I
confirmed it with the databook.

I hope to have revised schematics out by Tuesday next week.  Including the V40
and radio interface and power supply, etc.  Mike, if you could pass that
swallower circuit on to me on the back of an envelope or whatever by this
weekend, it would be much appreciated.  I am still leaning towards putting in
the pads and traces for 16 bit in and out ports, 2nd analog channel and
swappable 2k word memory (with the necessary parts for the "host" 320 to access
all the memory).

I am planning on using the V40 internal UART for the user interface and a DMAed
port of the SCC going to one 320 position, an interrupt-driven one going to the
second position.

I will probably be leaving the country a lot starting around the 1st of May, so
I am hopig to get this put to bed for the intitial Alpha cut of the hardware.
In this manner, I hope to use Eric as a resource to do board layout since he
will be convelescing at his house by then and running the PC requires little
physical effort.

I will post answers to specific queries that have been raised here, hopefully
tomorrow night.

Tomorrow, the local Motorola Field App Engineer comes to my office to bring me
up to dte on the 56001 and etc.

Lyle

#: 73445 S17/TAPR NNC/DSP
    06-Apr-88  03:32:10
Sb: #73252-Various 2 of 2
Fm: Phil Karn, KA9Q 73210,1526
To: Lyle Johnson, WA7GXD 76246,565

Lyle,

I agree strongly with the need for a kludge area. Make it bigger than you
think anyone will ever need! :-)

I also agree with getting rid of expensive LEDs and switches.  WITH ONE
EXCEPTION! I consider it absolutely essential that there be a
software-readable dipswitch register that can be used to configure the
unit at reset time.  To my knowledge, no TNC since the venerable TNC-1
has such a switch register, and the lack of same has made TNC multi-mode
operation a real pain.  This is especially true with unattended KISS
operation, when you want everything to come back up in the right mode
after a power hit with the least possible hassle.

Make the switch register at least 8 bits wide.  To keep costs low, you
can put it right on the circuit board.  It doesn't have to be readily
accessible, as long as it's there!

Phil

#: 73458 S17/TAPR NNC/DSP
    06-Apr-88  10:02:54
Sb: #73135-HF Modems
Fm: Barry McLarnon VE3JF 71470,3651
To: Bob McGwier N4HY 74615,1366

I agree... if we come up with something that doesn't work with nearly all
offthe-shelf radios, it isn't worth much.  I took a look at some of the current
crop of HF rigs to see just what is "standard".  All of them, of course, come
with an SSB filter, but the bandwidth varies from about 2.2 to 2.7 kHz.  Some
offer an optional 1.8 kHz BW filter.  Narrower filters still seem to be an
option in most sets... most of them offer a choice of one with 500-600 Hz BW,
or one around 250 Hz BW, or both.  Virtually all of them offer variable
bandwidth in the 500-2500 Hz range by virtue of their IF shift (VBT, passband
tuning, width, etc., etc.), so it's kinda hard to pin down a "standard"! Since
the AGC detector comes after this filtering, desense and pumping from
out-of-band signals should not be a problem.

My feeling is that we should aim for an emission that fits in a 1.8 kHz BW
filter.  It would then work ok with the wider 2.2 - 2.7 kHz filters, albeit
suboptimally, and they could be trimmed with the IF tuning controls to improve
the performance.  This is wide enough to offer good in-band frequency diversity
or frequency-domain coding performance.  It wouldn't work too well with the de
facto standard of 2 kHz channel spacing for HF packet though... we would
probably want to go to 3 kHz spacing.  We might also want to try a
stripped-down 300 bps emission with BW < 500 Hz.

Barry

#: 73467 S17/TAPR NNC/DSP
    06-Apr-88  12:32:38
Sb: #73446-HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Phil Karn, KA9Q 73210,1526 (X)

Yes, simply repeating bits is indeed called "repetition coding". The rest of
your statement is incorrect.  It doesn't make much sense to repeat a bit in a
chunk of time immediately adjacent in time to the first transmission of the
bit.  That would be just exactly like transmitting the bit for twice as long in
the first place.  So, you're right in thinking that there's no gain in
repeating IMMEDIATELY. But if you wait awhile, then repeat the bit, you gain
TIME DIVERSITY. Or if you repeat the bit on a different frequency (hopefully
not a directly adjacent frequency) then you get FREQUENCY DIVERSITY, etc.
Hopefully, you can arrange things so that the repeated symbol is far enough
away in time or frequency so that it fades independantly, or as much so as you
can manage.  This kind of diversity does provide a gain. Of course, if you're
going to transmit twice as many symbols, there are codes that can provide more
gain than repetition coding.  The only point i was trying to make was a
rebuttal to Tom's comment that you can't win by xmitting twice, because when
you combine a 1 and a 0 received you get a maybe.  That's wrong, because you
can (and should) soft combine, ie add the energies.

*** More ***

#: 73472 S17/TAPR NNC/DSP
    06-Apr-88  15:03:01
Sb: #73446-HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Phil Karn, KA9Q 73210,1526 (X)

Au contraire, mon ami!  This wasn't addressed to me, but I can't let it pass
without a rejoinder...

The idea was that we are sending the same data bit on two different
frequencies, hopefully spaced by more than the correlation bandwidth so that
they are fading independently.  This is much more useful than simply doubling
the length of the bit when we have selective fading.

Granted that repetition coding is not one of the more powerful codes (on the
other hand, if you have only one information bit to encode, what else is there?
:-)).  What we were specifically talking about here is applying coding in the
frequency domain to combat selective fading; i.e., transmitting n simultaneous
tones with an (n,k) code applied across them.  Because of the peak-to-average
ratio problem, we want to keep n as small as possible.  Hence the code is
necessarily a short one (we probably would also have coding in the time domain,
which could be quite different).  I submit that as the code length decreases,
all codes of the same rate approach the same performance, so the penalty
attached to using simple repetition coding will likely be small. And if the
competing code is decoded with hard decisions, the repetition code using analog
combining may actually do better.

I feel a digression coming on, so I'll put it in a separate message, which
follows.

*** More ***

#: 73473 S17/TAPR NNC/DSP
    06-Apr-88  15:03:58
Sb: #73446-HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Phil Karn, KA9Q 73210,1526 (X)

Several years ago I did some experiments with an 8-tone HF FDM modem (8
simultaneous 75 baud BFSK channels) configured in two different ways to produce
a half-rate (8,4) encoding with 300 bps throughput.  The 8 channels were
arranged in two groups of four, with the two groups separated by about 1.4 kHz.
The first arrangement used the repetition code, with the analog eye signals
from the four lower channels combined with their counterparts from the four
upper channels in four diversity combiners (maximal-ratio type, with weighting
according to SNR estimates for each channel) before hard-decision into 4 data
bits.  The second contender used an (8,4) extended Hamming code, which has
minimum distance 4 and is optimal for that length and rate.  This was
soft-decision decoded by digitizing the 8 eye signals at their maximum openings
and then finding which of the 16 valid codewords had the highest correlation
with the received vector of 8 sample values.  This was pretty easy, since this
code is biorthogonal (love dem buzzwords!) and half the codewords are
complements of the other half, so only eight correlations are needed each baud
interval.

Who won?  They both did!  They were being compared against a very fancy 300 bps
direct-sequence spread-spectrum HF modem, and both had significantly better bit
error rates.  The Hamming code did outperform the repetition code by a modest
amount, 26% lower overall error rate on one link, and 34% on another.  So n = 8
seems to be about the point where repetition code starts to look a little
shabby, but only if soft-decision decoding can be used with a more optimal
code.  This gets quite a bit harder to do when n > 8.

The half-rate repetition code has minimum distance 2 for all n, whereas the
achieveable minimum distance increases with n for better codes, e.g., 4 for the
(8,4) Hamming, and 8 for the (24,12) Golay.  So if we end up with a scheme with
fairly large n, it does behoove us to look at these other possibilities.

Next: The relationship between Golay codes and hockey pucks  ;-)

*** More ***

#: 73468 S17/TAPR NNC/DSP
    06-Apr-88  12:44:45
Sb: #73447-HF Modems, Part 2
Fm: Franklin Antonio, N6NKF 76337,1365
To: Phil Karn, KA9Q 73210,1526 (X)

You can, and people do, and i have, built soft decision decoders for block
codes.  The Chase algorithm is the algorithm of choice for his problem.

*** More ***

#: 73474 S17/TAPR NNC/DSP
    06-Apr-88  15:04:51
Sb: #73447-#HF Modems, Part 2
Fm: Barry McLarnon VE3JF 71470,3651
To: Phil Karn, KA9Q 73210,1526 (X)

Phil, while it's true that convolutional codes are naturally suited to using
quantized analog metrics in decoding, there's nothing to stop you from applying
similar "soft decision" techniques to block codes like Golay and Hamming, and
similar coding gains accrue when you do.  You just need different decoding
algorithms which make use of the additional quantized information.

I don't share your enthusiasm for convolutional coding on HF.  Long constraint
lengths are out of the question for Viterbi.  Sequential decoding?  Maybe, but
in general, convolutional codes just don't work well on bursty channels.  In
order to get anywhere near the theoretical coding gain, you have to randomize
the error patterns by putting a big interleaver in the encoded data stream.
Then you need another level of framing to sync the deinterleaver at the receive
end, and you have the delay while the interleaver fills up with data to contend
with.  Pretty messy.  I firmly believe that the best way to deal with a bursty
channel is not to try and randomize it, but to use a welldesigned ARQ protocol
to push data through between the error bursts.

On channels which are much closer approximations to Gaussian, like satellite
channels (especially the non-LEO orbiters) and EME (maybe), convolutional
coding could really shine.

Barry

*** There is a reply:   73502

*** More ***

#: 73502 S17/TAPR NNC/DSP
    07-Apr-88  01:41:41
Sb: #73474-HF Modems, Part 2
Fm: Phil Karn, KA9Q 73210,1526
To: Barry McLarnon VE3JF 71470,3651 (X)

Okay, I concede! It occurred to me after I sent my message and as
I read the remainder of your messages that I was still implicitly
thinking in terms of AWGN channels (I love those acronyms too!) which is
what almost all of the textbooks assume.  Yes, the situation for HF is
very different.

I've never taken a formal course in the subject.  So my knowledge of
coding theory is limited to what I've picked up informally from various
library textbooks.  I wasn't aware of the ability to extend block codes
to handle soft decisions.  If so, great -- that gets rid of the only
real objection I had.  I do think interleaving is something to look at,
since the HF channel is so highly time-varying.  I don't particularly
mind the decoding delays introduced by sequential decoding or by
interleaving, as most HF packet applications are likely to be
non-real-time (e.g., file transfers where you can compensate by just
opening up the flow control windows.) You just pick a time limit.  If
you run out, the decoder just abandons the packet and waits for a
retransmission.

Perhaps we should start by building a good software model of the HF
channel and using it to test our algorithms.  Is this practical? (It
should include some simulated Radio Moscow signals -- but be sure to use
a big enough word size to avoid amplitude overflow.  :-))

Moving up a level, I think we should give some thought to frame
structures (since we are going to support a packet network, right?) If
we're going to use block coding, a bit-oriented framing structure like
HDLC may be difficult to use.  How about a fairly long pseudo-random
sync vector sequence that indicates the start of each frame.  The vector
would be chosen, and the decoder implemented, such that you don't have
to have an exact match, as long as "most" of the bits are recognized.
If the vector is long enough and is chosen to be "different" enough from
the regular codewords, the chances of a false detection should be small.

Phil